Skilled Support Personnel (SSP) are specialists dispatched to aid first responders in emergency incidents. They include laborers, operating engineers, carpenters, ironworkers, sanitation workers and utility workers. SSP called to an emergency incident rarely have detailed and recent training on the chemical, biological, radiological, nuclear and/or explosives (CBRNE) agents or the personal protection equipment (PPE) relevant to the incident. This increases personal risk to the SSP and mission risk at the incident site. To reduce personal risk and increase the effectiveness of dispatched SSP at an emergency site, a system to provide detailed and specific just-in-time training (JITT) is desirable.
At first glance, it would appear that the pervasiveness of multimedia-enabled mobile devices would lend itself to accessibility for providing JITT over wireless networks. However, for the foreseeable future, the mobile marketplace will continue to witness variability in the multimedia capabilities of mobile devices and in standards compliance by device manufacturers and service providers. Interoperability between service providers is further hampered by their “walled garden” approach to media services and subscriber retention. Thus, there is a challenge in the delivery of cross-provider and cross-device mobile media in identifying which of the many media formats and delivery protocols are in fact supported by each user.
Some mobile devices are configured with Internet browsing capability. Mobile devices typically access web content using the Wireless Application Protocol (WAP). A microbrowser is a web browser designed for use on a mobile device. Microbrowsers are generally optimized to take into account memory capacity, bandwidth, and display size, which are often limited on mobile devices. A drawback of all microbrowsers, compared to desktop and laptop browsers, is their inability to simultaneously render imagery and audio. Specifically, microbrowsers pass any audio or video content encountered in a web page to the cell phone's built-in audio or video decoder (if it has one). The decoder then appears as a separate application on top of the microbrowser. This software architecture precludes the use of the GIF format as an alternate to video formats in web sites accessed by cell phones; a microbrowser user with a non-video-capable phone must chose between seeing the GIF animation and hearing the audio track.
In field tests in a 3 G supported area, only approximately 10% of mobile devices tested were able to access specific videos in a test to assess the percentage of new mobile devices that can view video over the web. The videos ranged from 95 KB to 1 MB in size, and were encoded in 64 kb/s 3gp (MPEG-4 15 f/s 176×144 pixel video and AMR audio), with landing pages simultaneously available in html, wml and xhtml. Therefore, Internet-based systems do not provide a reliable solution for providing multimedia content to mobile devices.
Mobile devices generally support the Multimedia Messaging Service (MMS) standard, which allows the sending and receiving of multimedia messages, such as video, audio and graphics. Multimedia messaging is included in base voice plans, unlike microbrowser operation, which typically requires the user to subscribe to an additional data plan.
However, interoperability between service providers is hampered by proprietary protocols and other approaches to multimedia services. From the physical layer to the application layer, competing standards create technical challenges in providing multimedia content to mobile devices. These competing standards include signal coding, media encoding, data encapsulation, delivery protocols and operating systems.
Content adaptation presents a further complication. Content adaptation refers to the server processes of detecting the media types supported by a client, detecting when information requested by a client includes media object types not supported by the client, and reformatting these media objects into client supported formats. However, the typical implementation of content adaptation by wireless service providers in their multimedia messaging servers is more a liability than an asset, and may result in the removal of multimedia content or non-delivery of the message.
The challenge facing the delivery of cross-platform and cross-device multimedia content is thus not one of developing a communications protocol, but of identifying which of the many available protocols and media formats are in fact supported by each user. Although standards for device profiling exist, not all device hardware manufacturers, device software developers, and wireless service providers reliably maintain these standards. Interoperability barriers to multimedia services stem from both technological issues and business plans.
International multimedia message protocols were initially defined only for the Global System for Mobile Communications (GSM) wireless standard prevalent in Europe and used by some US carriers, the largest of which are Cingular/ATT and TMobile. However, some of these protocols such as Wireless Application Protocol (WAP) Push cannot be implemented in the Code Division Multiple Access (CDMA) wireless standard used in the US by Verizon and Sprint.
Some middleware, such as Qualcomm's Binary Runtime Environment for Wireless (Brew) used by CDMA carriers, prevents users of non-smart phones from installing 3rd party applications. Subscribers can only install software purchased from that carrier.
User Agent Profiles (UAProfs), on-line descriptions of cell phones' hardware and software configurations (e.g., screen size, codecs), are intended to support the automated tailoring of media to the capabilities of the recipient's device (i.e., content adaptation), but are incorrect or missing for over 20% of devices, primarily CDMA devices.
75% of cell phone owners do not access the web with their device (or pay for the option). Hence, there is no header from which to obtain a User Agent Profilee (UAProf) location.
HTTP Get headers of microbrowsers in Microsoft Windows-based devices usually include only the non-descript */* in their ACCEPT tag and do not specify any UAProf at all.
When an MMS originates from a different wireless carrier, content adaptation and local number portability resolution can strip multimedia content from the message, delay the message by hours, or not deliver the message at all.
The most significant drawback to multimedia messaging is that messages must traverse numerous service provider protocols before reaching the user's cell phone, and each protocol imposes message content constraints. Service providers typically configure their cell phones to retrieve multimedia messages from their own message servers. In order to continue using this configuration, a JITT system must deliver multimedia messages via these same message servers.
Ultimately, a system design that incorrectly assumes a communications protocol standard will not be suitable for providing multimedia content to mobile devices in an environment where reliability is essential. Given the chaotic state of affairs in the wireless domain and the importance of reliability in some applications of providing mobile content, such as JITT for SSPs, the challenge facing the delivery of cross-provider and cross-device mobile media is the correct identification of the many media formats and delivery protocols supported by each mobile device.
Multimedia content is composed of individual assets, such as JPEG images and audio clips, arranged in space and time (screen layout and timeline) by a “wrapper”. The most prevalent multimedia wrappers and their associated delivery mechanisms are:
eXtensible HyperText Markup Language (XHTML) which is a text file which specifies the spatial layout of a web page. A microbrowser in a mobile device will recognize only basic XHTML commands, and rarely any proprietary extensions such as Internet Explorer's background sound. Assets are accessed via TCP-IP (i.e., the Internet), and wireless service providers typically charge extra for this connectivity. Any mobile device can receive the URL of an XHTML file via SMS, and some devices will retrieve the XHTML file with a simple click on the URL (instead of a copy-paste or retyping the URL in the microbrowser).
Synchronized Multimedia Integration Language (SMIL) is a text file which specifies the spatial and temporal layout of a multimedia message (including audio, picture and video messages). A multimedia message player can render background audio concurrently with imagery, which is an important instructional design advantage over a microbrowser. Assets are accessed by a multimedia message player via the MM1 wireless data protocol. Microbrowsers do not understand SMIL, although some are able to recognize a SMIL file when they encounter one, and relay it to the device's multimedia message player.
Video-Web pages and multimedia messages are collections of media files referenced by a text file written in XHTML or SMIL, respectively, whereas video is a single binary file. Nevertheless, video file extensions including .avi and .mov refer to the binary language of a wrapper that specifies the assets found in the same file, such as audio, video, caption, and hyperlinks. At a minimum, the wrapper component of a video file specifies the codec used to compress the audio and video components of the file. The MPEG-4 video codec and 3GPP file format were designed specifically for mobile devices (Apple and Real were leading contributors to these ratified standards), and Microsoft advocates its proprietary Windows Media Video format. Current video-enabled mobile devices will not render video in their microbrowser or multimedia message player; instead, any video file referenced in an XHTML or SMIL wrapper is relayed to the device's video player and rendered outside the XHTML or SMIL spatiotemporal context. A video player will have convenient controls for pause, play, forward, reverse, zoom, landscape, and portrait. Like SMIL, video renders animation with voiceover.